The small computer system interface (“SCSI”) protocol has become a ubiquitous protocol for formatting commands. Versions of the SCSI standard (e.g., SCSI-1, SCSI-2, SCSI-3) define both a set of commands (“SCSI commands”) a data transport protocol for sending the commands and a SCSI physical interface. SCSI commands can be encapsulated according to a variety of data transport protocols without using the SCSI data transport protocol or SCSI physical interface. Example protocols include fiber channel, serial storage architecture, serial bus protocol, iSCSI, advanced technology attachment (“ATA”), serial ATA (“SATA”), serial attached SCSI (“SAS”) and others. Thus, the SCSI standard separates the SCSI physical interface, SCSI command sets and the SCSI data transport protocol.
SCSI commands are used in a variety of data communications systems that utilize one or more data transport protocols. For example, SCSI commands are commonly used in fiber channel storage area networks (SAN) for commanding tape, disk and other storage devices to perform various operations. Because utilization of SCSI commands does not require utilization of the SCSI data transport protocol or interface, hosts operating according to the fiber channel data transport protocol can send commands understandable to devices operating according to the SCSI data transport protocol. However, while the SCSI commands can be sent using a variety of data transport protocols, the separation of SCSI commands from the SCSI data transport protocol can lead to operability issues when SCSI commands are sent using other data transport protocols. One example of this is found in the difficulty encountered when sending linked SCSI commands using the fiber channel data transport protocol.
The SCSI standard allows SCSI commands to be linked together. A bit in the command descriptor block (“CDB”) of a SCSI command can be set to specify whether or not the command is linked. A set of linked commands can specify data flow both to and from a target. Fiber channel devices, however, typically only allow data to be transported in one direction over an exchange. To send a command requiring data flow in the opposite direction of a previous command, the fiber channel device must typically open a new exchange, causing the link between the commands to be broken. Therefore, typical prior art fiber channel devices do not support linked commands requiring data flow in both directions. Additionally, prior art fiber channel devices do not typically support proprietary commands that require data flow in both directions.